The present invention relates to methods in an IP Multimedia Subsystem (IMS) which is a standardised architecture for telecom operators that want to provide mobile and fixed multimedia services. It uses a Voice-over-IP (VoIP) implementation based on a 3GPP standardised implementation of SIP, and runs over the standard Internet Protocol (IP). Existing phone systems, both packet-switched and circuit-switched, are supported.
The IMS services are provided by a number of IMS operators in co-operation. This is illustrated by op1 120a to op6 120f in FIG. 1. These IMS operators op1-op6 120a-f are interconnected through a closed interconnect/transit structure 100, an example of such an interconnect network is the by GSM Association proposed IP Exchange or IPX network provided by a set of IPX operators IPX1-IPX3 130a-c. In case of using IPX the IMS operators are connected to a few IPX operators while all IPX operators are interconnected making sure that between any two IMS operators there is at most two IPX operators. The IPX structure 130a-c constitutes an IMS transit layer on top of the GRX network 100.
The GRX network 100 was created to facilitate GPRS roaming and is implemented as an IP network separated from the Internet. The separation is such that the GRX network has its own DNS hierarchy 110 completely isolated from the Internet DNS 140 hierarchy.
The structures of the IMS interconnect DNS databases are as distributed as the Internet Domain Name System (DNS) database; all operators operate and administrate the internal structure of the domains they are responsible for. Only the top level services are present on the GRX network, they in turn point at the different operators DNS:es.
In the IMS, the additional identities IP Multimedia Private Identity (IMPI) and the IP Multimedia Public Identity (IMPU) are used to identify the user. The IMPI and the IMPU is a URI such like a phone number comprising digits or a SIP-URI comprising alphanumeric identifiers like “jan.svensson@operator.com”.
The IMPI is a unique identity normally stored at the ISIM that is used when registering a user in the IMS system and it is possible to have multiple IMPU per IMPI. The IMPU can also be shared with another phone, so both can be reached with the same identity (for example, a single phone-number for an entire family).
A user can have several Public Identities (IMPUs) that can be used in different situations. They can be seen as aliases so that the alternative IMPU “the plumber” can be used instead of the more formal IMPU “jan.svensson” if selected by the user Then, Jan Svensson will also when chosen be known as “the plumber” in the network. If another user wants to initiate a sip-call to Jan Svensson, in his role of “the plumber”, he can be reached on the address “the plumber@operator.com”.
If a user has several IMPUs they can be coupled together in implicit registered Id sets, meaning that when a user register with one of the IMPUs in the implicit registered Id set, the other IMPUs in the implicit registered Id set will also be registered.
The identities IMPU, IMPI, IMSI, and MSISDN are stored in the HSS (Home Subscriber Server) 204 shown in FIG. 2 that is the master user database supporting the IMS network entities that are actually handling the calls/sessions. Further, the HSS contains the subscription-related information (user profiles), performs authentication and authorization of the user, and can provide information about the physical location of user.
An IMS 200 connected to an access network 202 and to an IPX system 211 is illustrated in FIG. 2. An IMS user 201 connects to the IMS 200 via the access network 202.
The IMS network comprises a plurality of SIP servers and SIP proxies called CSCF (Call Session Control Function), used to process the SIP signaling packets in the IMS.
A P-CSCF (Proxy-CSCF) 203 is a SIP proxy that is the first point of contact for the IMS terminal.
An I-CSCF (Interrogating-CSCF) 208 is a SIP proxy located at the edge of an administrative domain. Its IP address is published in the DNS of the domain, so that remote servers (e.g., a P-CSCF in a visited domain, or a S-CSCF in a foreign domain) can find it, and use it as an entry point for all SIP packets to this domain. The I-CSCF queries the HSS to retrieve the user location, and then routes the SIP request to its assigned S-CSCF.
An S-CSCF (Serving-CSCF) 205 is the central node of the signaling plane. The S-CSCF downloads and uploads user profiles from the HSS since it has no local storage of the user.
Application servers (AS) 206 host and execute services, and interface with the S-CSCF using SIP. This allows third party providers an easy integration and deployment of their value added services to the IMS infrastructure.
An MRF (Media Resource Function) 207 provides a source of media in the home network. It is e.g. used for multimedia conferencing.
The I-BGF 210 is the border gateway function that is controlled by the I-BCF 209.
Users of IMS are allocated at least one Public User Identifier, referred to as IMPU above, of the address type SIP URI when they become IMS users. This has one identity part and one domain part. The domain name part is today always one of the domain names of the operator managing the user, thus taking the form ID1@op2.com or ID2@op5.com as indicated in FIG. 1. These identities can also be E164 numbers falling back to traditional telephony identifications in combination with domain names. They can also be aliases in case ID1 may be replaced with Al1 being an alias selected by the user ID1, and the same for the target user. The identities used are the one that the users want to publish and make known as their visible (by humans in end-points) IMS identities.
When the user ID1@op2.com wants to establish a session with the user ID2@op5.com the target address (ID2 or an alias) are put into the “To” field of the SIP invite signal. This Public User Identity is also populated in the “Request URI” field to be used in the SIP routing algorithms for example between the originating S-CSCF and the terminating I-CSCF in the involved IMS systems. The originating users identity ID1@op2.com is entered into the “From” field of the invite to provide a routable return address, and possible also a presentable identity of the calling party to the called party. FIG. 3 gives a SIP Invite example where this is shown.
The originating operator, op2, is the first to receive this invite. The invite is routed to the user's serving S-CFCF based on the parameters in the Route: header. After processing potential originating services the S-CSCF of the user at Op2 make a DNS lookup in the operator 2 internal DNS on the domain in the Request URI (op5.com) to find a routing direction, in this case as op5.com is not being served by this IMS domain it is pointing at the IPX Network and the entry point of IPX1. After some checking it is forwarded to IPX1 who in turn makes a DNS lookup in it's interconnect DNS on the domain in the request URI to find the next entry point. The entry point of IPX2 is found. The Invite is forwarded to IPX2 who do the same to find the entry point of op5. Op5 checks if the user ID2 is registered and, if so, forwards the invite to the S-CSCF where the user is served and routed the user's device via the P-CSCF handling the device.
The user ID2 device acknowledges the Invite signal and after user ID2 session acceptance the session is established.
Further, as stated above the SIP URI is built up of one individual part and one domain part defining the provider for the individual identity, ID@operator-domain.TLD, (TLD Top level Domain on the Internet, e.g. com) just like email addresses.
In the IMS standard it is assumed that the domain part actually points at the domain of the operator/provider and nothing else. This forms a problem for individuals and organizations that do not want to publish themselves as hosted by a provider but wants to be addressed through their private or their organizational domains.
One group is those that want their SIP URI to be like ID@private-domain.TLD, thus no operator/provider domain is present in that SIP URI.
Another group is organizations that want their SIP URI to reflect their organization rather that their provider domain like employee@enterprise-domain.TLD or member@organisation-domain.TLD, which imply that there is no operator/provider domain present in that SIP URI.
The IMS Standard has not shown how this can be achieved as of today. In all examples the provider domain is necessary for the communication between the functional entities inside each IMS provider's network implementation.